Authenticated/Encrypted DNS, DNSSEC (over clearnet or Tor)

Documentation for this is incomplete. Contributions are happily considered! See this for potential alternatives.

Warning: This is for testers-only!

Introduction[edit]

TODO: brief introduction what DNS is, current status of widespread insecure DNS

DNS Resolver Features[edit]

Recursive:
A recursive DNS lookup is where one DNS server communicates with several other DNS servers to hunt down an IP address and return it to the client. Recursively querying a host that is not cached as an address, the resolver needs to start at the top of the server tree and query the root servers, to know where to go for the top level domain for the address being queried.
^[1]
- Opposite of recursive, is iterative:
  an iterative DNS query, where the client communicates directly with each DNS server involved in the lookup.
  ^[2]
Authentication:
- DNSSEC:
  The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.
- Validating: perform DNSSEC authentication, end-to-end verification of DNSSEC.
  - Opposite of validating is non-validating.
encryption:
- DNS over TLS (DoT): Encrypted DNS. (Port 853).
- DNS over HTTPS (DoH): Encrypted DNS, similar to above but provides better censorship circumvention in theory as it uses the commonly used web https port 443.
- Opposite of encryption is unencrypted.
caching:
To avoid having to take the performance hit of issuing multiple iterative request to other DNS servers every time it receives a recursive request, the server caches its results.
^[3]
- Opposite of caching is non-caching.

DNS Encryption[edit]

DNS encryption does not imply DNS authentication.

root name servers[edit]

Root name servers do not support encryption yet.

DoT vs DoH[edit]

Quote https://blog.apnic.net/2020/12/14/dns-over-https-in-unbound/

There are, however, DNS clients that do not support DoT but are able to use DNS-over-HTTPS (DoH) instead. Where DoT sends a DNS message directly over TLS, DoH has an HTTP layer in between. Where DoT uses its own TCP port (853), DoH uses the standard HTTPS port (443). Using the standard HTTPS port makes it harder to block DoH queries, as blocking TCP traffic on port 443 will also block a lot of web traffic. Some people think this is great as this ensures that the user’s DNS queries will always be encrypted; others have concerns about DoH as they might lose control over clients in their network. At NLnet Labs we are in favour of encrypting DNS traffic to limit the exposure of privacy-sensitive data. By adding downstream DoH support to Unbound we hope to increase the ratio of encrypted DNS traffic and increase the number of resolvers that offer encrypted services in home networks, enterprise networks, ISPs, and public resolvers.

There was some bad press about DoH. ^[4] There are some stakeholders who find DoH troublesome (oppressive governments, censors, corporate network administrators) however see this rebuttal by the DoHoT project. It would also be problematic if browser vendors such as Google Chromium of Mozilla Firefox enabled DoH by default. That is because it delegates the power which website remains reachable and which gets blocked in DNS from the internet service provider (ISP) to the browser vendor. Firefox enabled DoH by default in USA. ^[5] In conclusion, an end-user having awareness of their DNS setting that opt-in to reconfigure on their system level to use either an DoT or DoH server should have only advantages and no disadvantages.

Here is a big DNS over HTTPS (DoH) server list.

DNS Authentication[edit]

There is a difference between a local DNSSEC aware resolver and a local DNSSEC validating resolver.

At the time of writing, no major end-user operating system performs DNSSEC validating by default. ^[6]

When enabling DoH in some web browsers such as Mozilla Firefox, there is no authentication yet. In other words, Firefox does not perform local DNSSEC validation yet.

https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_do-you-validate-dnssec

DNS Resolving Security Feature Wishlist[edit]

Ideally, all of the following security properties would be fulfilled by a local DNS resolver setup the same time:

Recursive: One would want to get the information from the most authoritative source, starting from the root name servers instead of iterative "asking a third-party server".
Authentication:
- DNSSEC: authenticating DNSSEC signed DNS data.
- Validating: Locally verifying DNSSEC signatures instead non-validating, i.e. trusting a remote DNS server to do that.
Encryption: To protect non-DNSSEC data from malicious manipulation through man-in-the-middle attacks (injection of advertisements, malicious redirects, malware), to protect network neutrality, privacy and for circumvent censorship.

TODO:
- anon-dns
- onion

DNS Security Optimization Problem[edit]

At the moment it is impossible to get all features from the DNS Resolving Security Feature Wishlist at the same time.

Since root name servers are required for recursive DNS resolution but do not support encryption yet, it is at time of writing impossible to have both, recursive and encrypted DNS resolution.

The author of this wiki page is unaware of any DNS resolver software with DNS encryption features which would also perform local DNSSEC validation on the user's computer.

dnscrypt-proxy is DNSSEC aware but dnscrypt-proxy at time of writing is DNSSEC non-validating. ^[7]
cloudflared is DNSSEC non-validating? ^[8]
systemd-resolved: Has at time of writing an non-acknolwedged bug report resolved DNSSEC validation can be bypassed by MITM and a feature request local DNSSEC validation which asks to clarify if systemd-resolved is a DNSSEC aware or local DNSSEC validating DNS resolver. See also: resolved DNSSEC validation can be bypassed by MITM

When a user is using dnscrypt-proxy or cloudflared, the user must choose one or multiple specific DNS servers used for DNS resolution (iterative DNS resolver). I.e. the user can not these programs as recursive DNS resolver.

It is a difficult choice to make. Depends on the user's threat model.

The user either trusts the root DNS servers or third-party servers.
- TODO: expand

There are various options.

A) The start situation in which most users are in. Without any configuration, most users use their internet service provider's DNS server which often is DNSSEC unaware. Even if DNSSEC aware, the ISP would do validation for the user since as mentioned above, no (mainstream) operating systems at the time of writing perform local DNSSEC validation. Therefore the user is vulnerable to malicious DNS through a man-in-the-middle attack on DNS for both, DNSSEC secured and DNSSEC unsecured domains.
B) Using encrypted DNS without local DNSSEC validation with a trusted DNS server should by definition prevent a man-in-the-middle attack on DNS for both, DNSSEC secured and DNSSEC unsecured domain names. But then which DNS servers are really considered trusted by user? Most users do not wish to trust any third-parties if not unavoidable.
C) Using authenticated DNS (performing local DNSSEC validation) without encryption in iterative mode using any supported DNS servers. Which DNS servers support that? In iterative mode, can DNS servers just lie and pretend "no DNSSEC available that domain name?"
D) Using authenticated DNS (performing local DNSSEC validation) without encryption in recursive mode without needing to trust any DNS server. In that case, the user has much higher certainty ^[9] that any DNSSEC secured domains will be properly resolved. Any malicious modifications by a man-in-the-middle attack on DNSSEC secured DNS replies would be detected. However, DNSSEC unsecured domains would still be vulnerable to man-in-the-middle attacks. Perhaps even more vulnerable since a recursive DNS resolver makes much more requests to much more targets on the internet. It depends on where the user would consider man-in-the-middle attack to be most likely. From their computer to their ISP or anyone in between or rather anyone outside their ISP network.

For all options equally applies that a man-in-the-middle attacker could attempt a denial of service of all of the user's DNS requests. This would likely lead to the user believing that their DNS configuration is broken and perhaps to downgrade to insecure options such as going back to their ISP's DNS server. It might be possible to reduce this risk by tunneling all DNS traffic over Tor.

Potential Obstacles[edit]

This is a list of things the user should know before and after considering to modify the system default DNS resolution. Sorted in order of likelihood. Most likely obstacles are on top of the list.

Websites based tests might be dysfunctional, show false-positives.
A browser extension such as noscript breaking website based tests.
Issues introduced though use of a tunnel-link such as a VPN.
Some domains can be resolved while others fail.
VirtualBox users: VBoxManage modifyvm "$VMNAME" --natdnsproxy1 on breaks DNS.
The user's computer has a local IPv6 but no actual IPv6 connectivity which might confuse DNS resolvers such as unbound.
The web browser might have a bug that disables DNSSEC.

Many applications do actually not use system DNS but their own internal DNS implementation.

The web browser might not use system DNS but use its own DNS.
- Firefox in USA comes with its own DoH enabled by default. ^[10]
- Tor Browser does not use system DNS but uses Tor to resolve DNS.
- Other web browsers not listed here might use similar implementations.
- Check browser settings or use search engines on how to view/change these settings.
Android has private DNS.
Other applications (non-browser) might use similar implementations.

In other words, changing system DNS settings according to this wiki page might not result in changes how the web browser resolves DNS. For example, Firefox in USA would still use its internal DoT default setting, unless modified by the user to use system DNS.

To test if the browser (or any other application) uses system DNS or its own internal DNS implementation, the user could temporarily disable their system DNS resolution.

To disable system DNS resolution...

1. Edit the /etc/resolv.conf system wide DNS configuration file

sudoedit /etc/resolv.conf

2. Disable all settings by adding a hash (#) in front of it.

3. Done.

The process of disabling system DNS has been completed.

Unbound[edit]

Unbound (unbound security audit) (in Debian) is a is a validating, recursive, and caching DNS resolver with DoT and DoH support. In context of censorship circumvention, routing DoT over Tor is possible and fast enough according to the DoHoT: making practical use of DNS over HTTPS over Tor.

1. Choose an option.

recursive, unencrypted, validating, caching

No extra steps required for this options.

iterative, encrypted (DoT), validating, caching

1. Create folder /etc/unbound/unbound.conf.d.

sudo mkdir --parents /etc/unbound/unbound.conf.d

2. Open file /etc/unbound/unbound.conf.d/50_user.conf in an editor with root rights.

See Open File with Root Rights for detailed instructions on why to use sudoedit for better security and how to use it.

sudoedit /etc/unbound/unbound.conf.d/50_user.conf

NOTES:

When using Kicksecure-Qubes, this needs to be done inside the Template.

sudoedit /etc/unbound/unbound.conf.d/50_user.conf

After applying this change, shutdown the Template.
All App Qubes based on the Template need to be restarted if they were already running.
This is a general procedure required for Qubes and unspecific to Kicksecure for Qubes.

This is just an example. Other tools could achieve the same goal.
If this example does not work for you or if you are not using Kicksecure, please refer to this link.

sudoedit /etc/unbound/unbound.conf.d/50_user.conf

3. Paste the following lines. ^[11]

Note: The user is free to add, remove, modify the servers at the bottom of the following configuration snippet.

server: #verbosity: 5 hide-identity: yes hide-version: yes interface: 127.0.0.1@53 interface: ::1@53 port: 53 do-ip4: yes do-ip6: no do-udp: no do-tcp: yes tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" forward-zone: name: "." forward-tls-upstream: yes # Freifunk München forward-addr: 195.30.94.28@853#dot.ffmuc.net # Digitalcourage e.V. forward-addr: 46.182.19.48@853#dns2.digitalcourage.de # Digitale Gesellschaft (CH) DNS Server forward-addr: 185.95.218.42@853#dns.digitale-gesellschaft.ch forward-addr: 185.95.218.43@853#dns.digitale-gesellschaft.chforward-zone: # Cloudflare forward-addr: 1.1.1.1@853#cloudflare-dns.com forward-addr: 1.0.0.1@853#cloudflare-dns.com

4. Save.

2. Install dnssec-trigger. ^[12]

Install package(s) dnssec-trigger following these instructions

Platform specific notice.

Kicksecure: No special notice.
Kicksecure-Qubes: In Template.

Update the package lists and upgrade the system .

sudo apt update && sudo apt full-upgrade

Install the dnssec-trigger package(s).

Using apt command line --no-install-recommends option is in most cases optional.

sudo apt install --no-install-recommends dnssec-trigger

Platform specific notice.

Kicksecure: No special notice.
Kicksecure-Qubes: Shut down Template and restart App Qubes based on it as per Qubes Template Modification .

Done.

The procedure of installing package(s) dnssec-trigger is complete.

3. Done.

The process is complete.

Testing DNSSEC[edit]

Browser Tests[edit]

DNSKEY Test[edit]

1. Learn how to interpret the results.

See the following A) vs B).

A) Something similar to the following would be showed if the system resolver does not have DNSSEC support.

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> +multiline . DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 42982
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; WARNING: EDNS query returned status NOTIMP - retry with '+noedns'

;; QUESTION SECTION:
;.			IN DNSKEY

;; Query time: 0 msec
;; SERVER: 10.139.1.1#53(10.139.1.1)
;; WHEN: Wed Jul 17 17:41:33 UTC 2019
;; MSG SIZE  rcvd: 17

B) Something similar to the following would be showed if the system resolver has DNSSEC support.

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> +multiline . DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63055
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1252
;; QUESTION SECTION:
;.			IN DNSKEY

;; ANSWER SECTION:
.			8461 IN	DNSKEY 256 3 8 (
				AwEAAcTQyaIe6nt3xSPOG2L/YfwBkOVTJN6mlnZ249O5
				Rtt3ZSRQHxQSW61AODYw6bvgxrrGq8eeOuenFjcSYgNA
				McBYoEYYmKDW6e9EryW4ZaT/MCq+8Am06oR40xAA3fCl
				OM6QjRcT85tP41Go946AicBGP8XOP/Aj1aI/oPRGzRnb
				oUPUok/AzTNnW5npBU69+BuiIwYE7mQOiNBFePyvjQBd
				oiuYbmuD3Py0IyjlBxzZUXbqLsRL9gYFkCqeTY29Ik7u
				suzMTa+JRSLz6KGS5RSJ7CTSMjZg8aNaUbN2dvGhakJP
				h92HnLvMA3TefFgbKJphFNPA3BWSKLZ02cRWXqM=
				) ; ZSK; alg = RSASHA256 ; key id = 59944
.			8461 IN	DNSKEY 257 3 8 (
				AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
				iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
				7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
				LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
				efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
				pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
				A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
				9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
				) ; KSK; alg = RSASHA256 ; key id = 20326

;; Query time: 0 msec
;; SERVER: 127.0.2.1#53(127.0.2.1)
;; WHEN: Wed Jul 17 17:43:09 UTC 2019
;; MSG SIZE  rcvd: 578

2. Run the following command.

dig +multiline . DNSKEY

3. Internet the result.

4. Done.

DNSSEC DNSKEY test has been completed.

dig +dnssec Test[edit]

Test with dig.

dig +dnssec nic.cz @localhost

Please refer to upstream documentation on how to interpret the DNSSEC test results.

DoHoT[edit]

https://github.com/alecmuffett/dohot/issues/4

References[edit]

TCP - https://ns1.com/blog/dns-over-tcp-as-seen-from-the-authoritative-server

Footnotes[edit]

Kicksecure

A secure by default operating system with the latest security research in place.

Dark mode

Supported by Power Up Privacy

Kicksecure is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

[1] ttps://wiki.archlinux.org/title/unbound

[2] ttps://www.cloudflare.com/learning/dns/what-is-recursive-dns/

[3] ttps://www.digitalocean.com/community/tutorials/a-comparison-of-dns-server-types-how-to-choose-the-right-dns-configuration

[4] ZdNet: DNS-over-HTTPS causes more problems than it solves, experts say

[5] ttps://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_are-you-rolling-this-default-out-in-europe

[6] 
https://wiki.debian.org/DNSSEC

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj200221(v=ws.11)

https://security.stackexchange.com/questions/93879/non-validating-dnssec-aware-client-security-implications

[7] ttps://wiki.debian.org/DNSSEC

[8] ttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj200221(v=ws.11)

[9] ttps://security.stackexchange.com/questions/93879/non-validating-dnssec-aware-client-security-implications

[7] ttps://github.com/DNSCrypt/dnscrypt-proxy/issues/167#issuecomment-367689381

[8] ttps://community.cloudflare.com/t/does-the-cloudflared-dns-client-locally-verify-dnssec/335402

[9] Ignoring potential exploitation of the DNS resolver software.)

[10] ttps://www.zdnet.com/article/mozilla-enables-doh-by-default-for-all-firefox-users-in-the-us/

[11] ttps://www.privacy-handbuch.de/handbuch_93c.htm

[12] ttps://nlnetlabs.nl/projects/unbound/about/

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

DNS Security

Contents

Introduction[edit]

DNS Resolver Features[edit]

DNS Encryption[edit]

root name servers[edit]

DoT vs DoH[edit]

DNS Authentication[edit]

DNS Resolving Security Feature Wishlist[edit]

DNS Security Optimization Problem[edit]

Potential Obstacles[edit]

Unbound[edit]

recursive, unencrypted, validating, caching

iterative, encrypted (DoT), validating, caching

Kicksecure

Kicksecure for Qubes

Others and Alternatives

Testing DNSSEC[edit]

Browser Tests[edit]

DNSKEY Test[edit]

dig +dnssec Test[edit]

DoHoT[edit]

References[edit]

Footnotes[edit]

Navigation menu

DNS Security

Introduction[edit]

DNS Resolver Features[edit]

DNS Encryption[edit]

root name servers[edit]

DoT vs DoH[edit]

DNS Authentication[edit]

DNS Resolving Security Feature Wishlist[edit]

DNS Security Optimization Problem[edit]

Potential Obstacles[edit]

Unbound[edit]

recursive, unencrypted, validating, caching

iterative, encrypted (DoT), validating, caching

Kicksecure

Kicksecure for Qubes

Others and Alternatives

Testing DNSSEC[edit]

Browser Tests[edit]

DNSKEY Test[edit]

dig +dnssec Test[edit]

DoHoT[edit]

References[edit]

Footnotes[edit]

Navigation menu

Search